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(57) A method for converting an interface definition 
description and an inter-object communication method, 
in which a service provider can control a message deliv- 
ery method to realize communication based not on 
object designation bui on service designation. In the 
methods, a client stub (1c), a server skeleton (2s) and a 
routing program (1r,2r) are generated from an interface 
definition defined by the service provider. A client object 
(10) calls the client stub, and sends a message whose 
send destination is specified by an interface name. The 
server skeleton registers a provided service in a routing 
information table (31). A router (12.22) determines a 
server object (20) as the send destination on the basis 
of a routing program associated with the interface name 
of the send message, a message queue information 
table (30) and the routing information table (31), and 
sends the message. 




CD 



Q. 

UJ 



1 EPI 

Description 

BACKGROUND OF THE INVENTION 

The present invention relates to an inter-object 5 
communication method in an application which uses a 
plurality of objects to be operated on a single computer 
or on a plurality of computers connected in a network 
and more particularly, and also relates to a method for 
converting an interface definition in such an application. >o 

Conventional inter-object communication method in 
an application which uses a plurality of objects to be 
operated on a single computer or on a plurality of com- 
puters connected in a network, includes a common 
object request broker architecture (CORBA)(Architec- 75 
ture and Specification Revision 2.0, July 1995, OMG) in 
the Object Management Group (OMG). In the CORBA, 
when interface defnition language (IDL) is used, an 
object interface can be defined independently of a pro- 
gramming language for describing the objects. so 

When an interface definition described in the IDL is 
converted by an IDL compiler, there are automatically 
generated a client stub (term often used in the above 
CORBA) associated with a client program to play a role 
in sending a message from the client program to a is 
server program as well as a server skeleton (term often 
used in the above CORBA. which is also a template for 
processing description) corresponding to a description 
pari of the server program other than an original 
processing description part thereof, thus enabling relief 30 
ol programmer's burden. 

Actual communication between the programs is 
earned out on the basis of the object request broker 
(ORB) technique. 

The client program searches for a communication 35 
destination object on the basis of the name, acquires as 
its searched result an object reference (which is infor- 
mation indicative of the presence location of the object 
(server program)) associated with the server program 
corresponding to the object in a one-to-one relationship; 40 
whereas, the client program transmits a message to the 
server program by calling a client stub generated from 
the interface associated with the object reference. 

Thereby a programmer ol the client program can 
describe the original-processing description part of the « 
application program without recognizing the physical 
position of the server program or the actual protocol. 

Meanwhile, a programmer of the server program is 
only required to describe only the original processing of 
the application program without recognizing the actual so 
communication protocol. 

SUMMARY OF THE INVENTION 

H is therefore an object of the present invention 1o 55 
provide a programming method centered on the original 
processing (service) provided by a server object while 
securing the above advantages of a CORBA, and also 
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to provide an inter-object communication method. 

The object includes five sub-objects which follow. 

First one of the sub-objects is to enable communi- 
cation with the server object which provides a service 
without any need for specifying the object itself, by 
specifying the service. 

Second one of the sub-objects is to suitably deliver 
a communication message to the server object which 
provides the service. 

Third one of the sub-objects is to eliminate the need 
for modifying the client object at the time of adding, 
deleting or modifying the server object which provides 
the service. 

Fourth one of the sub-objects is to enable the serv- 
ice provider and the programmer of the server cib^pfo- - 
control the message distribution method. 

Fifth one of the sub-objects is to centralizedly man- 
age a program module associated with one application 
to simplify its installing operation. 

In accordance with an aspect of the present inven- 
tion, the above objects can be attained by providing a 
method for converting an interface definition description 
in an inter-object communication system wherein a cli- 
ent object operating on either one of a plurality of com- 
puters in a network or on a single computer sends a 
message to a server object operating on the same or 
another computer to execute a predetermined process- 
ing operation. 

In this invention, the method includes the step of 
causing an interface definition converting program to 
convert the interlace definition description described in 
an interface definition language to thereby generate a 
client stub, a server skeleton and a routing program. 
The interface definition description includes one or 
more of data necessary for the predetermined process- 
ing operation, a method definition description of a 
processing result, and a message description for speci- 
fying a format of the message to be sent in response to 
the method definition description. The client stub is 
called to cause the client object to send the message. 
The server skeleton includes a server registration 
method for storing, in routing information memory 
means, routing information lor specifying the formal of 
Ihe message which the server object itself can process 
when started and also includes a method for descrtoing 
the predetermined processing operation to be executed 
when the server object receives the message. The rout- 
ing program judges whelher or not the processing of the 
server object associated with the routing information of 
the message is possible through comparison between 
the message and the routing information. 

In accordance with another aspect of the present 
invention, there is provided an inter-object communica- 
tion system wherein a client object operating on either 
one of a plurality of computers in a network or on a sin- 
gle computer sends a message to a server object oper- 
ating on the same or anolher computer to execute a 
predetermined processing operation. In this method, a 
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client stub, a server skeleton and a routing program 
generated through the above conversion are stored in 
the computers. When the server object is started, a 
server registration method is called and routing informa- 
tion is stored in routing information memory means to 5 
cause the client object to call the client stub to send the 
message and to hold the sent message in a send mes- 
sage queue. A router extracts the message from the 
send message queue, lo determine a send destination 
object according to the routing program and to add the w 
received message in a receive message queue associ- 
ated with the send destination object. The server skele- 
ton extracts the message from the receive message 
queue and the server object executes the predeter- 
mined processing operation of the message extracted 15 
by the server skeleton. 

In the method, the routing program adds a queue- 
ing option description including a message maximum 
number designation and a queueing time designation to 
a message description of the interface definition 20 
descrption. compares the message and the routing 
information to judge whelher or not the processing oper- 
ation by the server object associated with the routing 
information of the message is possible and, in the case 
of presence of the message maximum number designa- 25 
tion, performs the queueing option judging operation. 

In the inter-object communication system, the 
router keeps the message extracted from the send mes- 
sage queue in a temporary keep message queue, and 
when another message has the same contents as the 30 
kept message, the router integrates the messages into 
a single message, and when the number of messages 
within the temporary keep message queue exceeds the 
message maximum number or when the queueing time 
elapses after the message is queued, the router adds 35 
the message to a receive message queue associated 
with the send destination object. 

In the method, in place ol the routing program, such 
a custom routing program is generated as to compare 
the message and the routing information to judge 40 
whether or not the processing operation by the server 
object associated with the routing information of the 
message is possible and to perform the matching option 
judging operation. 

In the inter-object communication system, further. 45 
the client stub, the server skeleton and the routing pro- 
gram are combined into a single server object to store 
the service object in a service object memory means; 
the server object is extracted from the service memory 
means to call the client stub before the dient object 50 
sends a message; the server object is extracled from 
the service memory means to call the routing program 
before the router determines the send destination 
object; and the server object is extracted from the serv- 
ice memory means to call the server skeleton at the 55 
time of starting the server object. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a general arrangement of an embodi- 
ment of the present invention; 
Frg. 2 shows a structure of an IDL compiler and a 
relationship thereof with an interface definition file, 
a client stub, a server skeleton, a routing program; 
Fig. 3 is a flowchart for explaining how to generate 
the client stub; 

Fig. 4 is a flowchart for explaining how to generate 
the server skeleton; 

Fig. 5 is a flowchart for explaining how to generate 
the routing program; 

Fig. 6 shows an exemplary structure of the interface 
definition file; 

Fig. 7 shows an exemplary structure of the client 
stub; 

Fig. 8 shows an exemplary structure of the server 
skeleton; 

Fig. 9 shows an exemplary structure of the routing 
program; 

Fig. 10 shows a structure of a message queue; 
Fig. 1 1 is a structure of a message queue informa- 
tion table; 

Fig. 12 shows a structure of a routing information 
table; 

Fig. 13 is a flowchart for explaining a client stub 
process; 

Fig. 14 is a flowchart tor explaining a server skele- 
ton process; 

Fig. 15 is a flowchart for explaining a routing proc- 
ess; 

Fig. 16 shows an arrangement of an inter-object 
communication system using a dynamic service 
object loader; and 

Fig. 17 shows a structure of a server object. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

An embodiment of the present invention will be 
detailed below with reference to the drawings. 

Referring first to Fig. 1, there is shown an entire 
arrangement of an embodiment of the present inven- 
tion. 

In the present embodiment, computers 1, 2 and 3 
are connected in a network 8. 

A client object 10 as a program for requiring a serv- 
ice to a server is present in the computer 1, and, a 
server object 20 as a program for executing a service in 
response lo a request from a client is present in the 
computer 2 independently from each other. 

In the inter-object communication of the present 
invention, however, it is possible that a client object 10 
and the server object 20 are both present in the same 
computer 6 as shown in Fig. 16. and it is also possible 
that a plurality of client objects 10 and a plurality of 
server objects 20 are mixedly present in a single com- 
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pirter. 

In addition, it is also possible to place a memory 3m 
of the computer 3 in the computer 1 or 2. 

Fig. 2 schematically shows how to generate a client 
stub 1 c tor sending a message from the client program s 
to the server program, a server skeleton 2s for serving 
as a template for processing description of the server 
program, and a routing program 1r for judging whether 
or not the service can be processed by the server object 
on the basis of the received message, from an interface u 
definition file 4 prepared in an interface definition lan- 
guage (IDL) by a service provider with use of an inter- 
face definition conversion program 5 (IDL compiler 5). 

The IDL compiler 5 includes a lexical analyzer 50. a 
parser 51 . a client stub generator 52, a server skeleton 75 
generator 53 and a routing program generator 54. 

The lexical analyzer 50 analyzes a token while 
reading the interface definition file 4 and provides infor- 
mation on the read token to the parser 51 . 

The parser 51 performs its analyzing or parsing so 
operation using the above information and calls the cli- 
ent stub generator 52. server skeleton generator 53 and 
routing program generator 54. 

Shown in Fig. 6 is a structure of an example of the 
interface definition file. 25 

The interface definition file 4 is a further extension 
of the IDL description used in the CORBA 

The interface definition file 4 has a native method 
description 40 tor calling an external method, and 
method definitions 4 1 and 42 corresponding to services 30 
provided by the server object. 

The method definition 41 has a method declaration 
(corresponding to a description "void search... Excep- 
tion" given under Method Definition 1) used in the 
CORBA, a message description 410 and a matching 35 
option description 411 for performing a strict matching 
operation based on user's instruction as an option. 

The matching option description 41 1 is descrbed in 
a language independent format as in the case where 
the CORBA IDL description is language-independent. 40 

The example of Fig. 6 shows the message descrip- 
tion 410 indicating that a communication message has 
a pattern of "search $keyword", where a token starting 
with $ is a parameter. 

The matching option description 411 is one which « 
judges whether or not the parameter "Skeyword" can be 
processed with use of the method "isSupportCate- 
gory()" declared in the native method description 40. 

The message description 410 may include a 
qu eueing option description 4 1 00 as an option. 50 

In the example of Fig. 6, the maximum number 
'maximum' of messages handleable in the message 
integrating operation is specified to be 100, and the 
longest message queueing time is specified to be 60 
seconds. 55 
The message integration will be described later. 
Fig. 7 shows a structure of an example of the client 
stub compiled and generated by the IDL compiler from 



the interface definition file 4 shown in Fig. 6 as an exam- 
ple. The generated client stub 1 c is described in source 
level language. In the example of Fig. 7, C++ is used as 
a programming language after the compilation. 

The client stub 1c in compiled code is prepared by 
compiling a client stub header file 1cf 1 and a client stub 
source file 1cf2. 

The client stub header file 1cf1 includes messaging 
method declarations 1cf11 and 1cf12 called by the cli- 
ent object 10. 

The client stub source file 1cf2 includes messaging 
method definitions 1cf21 and 1cf22. 

Shown in Fig. 3 is a flowchart for explaining a client 
stub generating process by the client stub generator 52. 

A client stub generating process 520, when called 
by the parser 51. analyzes the interface definition file 4 
sequentially from the method definition 41 therein, 
repeats Hs subsequent processing operations on the 
basis of a judgement step 521 on whether or not there 
is a method definition, and H there is no definition, termi- 
nates Hs operation at an end step 527. 

In compiling the method definition 41 . at a messag- 
ing method declaration code generation step 522. there 
are generated the messaging method declaration 1cfl 1 
and a protocol type declaration part (which corresponds 
to "void DigitalLforary... Exception" given below the 
Messaging Method Definition. The declaration part in 
the C++ language is also called a prototype declaration 
part) of the messaging method definition 1cf21. 

Next, at a message pattern string definition code 
generation step 523, codes for preparation of a mes- 
sage string not containing a parameter are generated in 
the messaging method definition 1cf21. 

When a parameter is present in the message string, 
the system repeats the operation of a parameter setting 
code generation step 525 on the basis of a judgement 
result of the step 524 indicative of the presence of 
absence of a parameter. At the parameter setting code 
generation step 525, the system generates in the mes- 
saging method definition 1cf21 codes for addition of a 
parameter string to the above message siring. 

Finally, at a message sending code generation step 
526, the system generates in the messaging method 
definition 1cf21 codes for calling of a message sending 
function of a message communication library 11 (see 
Fig. 11) with use of an interface name ("DigitalLibrary") 
and the message string as parameters. 

Fig. 8 shows a structure of an example of the server 
skeleton compiled and generated by the IDL compiler 
from the interface definition file 4 of Fig. 6. The gener- 
ated server skeleton 2s is described in source level lan- 
guage. Even in the example of Fig. 8, C++ is used as a 
programming language after the compilation. 

The server skeleton 2s in compiled code is gener- 
ated by compiling a server skeleton header file 2sf1 and 
a server skeleton stub source file 2sf2. 

The server skeleton header file 2sf1 includes a reg- 
istration method declaration 2sf 1 0 to be called for regis- 
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tration erf the server object 20 in the routing information 
table (see Fig. 1) at the time of activating the server , 
object 20 and messaging handler declarations 2sf11 
and 2sf12. 

The server skeleton stub source I ile 2sf2 includes a 5 
registration method definition 2sf20 and messaging 
handler def initions 2st21 and2sf22. 

Fig. 4 is a flowchart for explaining the operation of a 
server skeleton generation process 530 by the server 
skeleton generator 53. w 

The server skeleton generation process 530 is 
called by the parser 51. 

At a registration method declaration code genera- 
tion step 531, the system generates the registration 
method declaration 2sf10 and a prototype declaration is 
part (corresponding to "void DigftaL.registerO" given 
below the Registration Method Definition) of the regis- 
tration method definition 2sf20. 

At a server registration code generation step 532, 
Ihe system generates in the registration method defini- 20 
tion 2sf20. a code for registration of the server object 20 
(refer to Fig. 1) in the routing information table (refer to 
Fig. 1) with use of the interface name ("DigitalLibrary") 
as an argument. 

Next, the system analyz es the method definition 4 1 25 
of the interface definition file 4 (refer to Fig. 6) sequen- 
tially, repeats the subsequent operations on the basis of 
a judgement result of a step 533 of judging the presence 
or absence of a method delinrtion. and in the absence of 
a definition, terminates Ms operation at an end step 536. 30 

At a message handler declaration code generation 
step 534, the system generates the messaging handler 
declarations 2sf 1 1 and 2sf12 as well as prototype dec- 
laration parts (corresponding to "void Digital... .keyword" 
given below Message Handler Definitions 1 and 2) of as 
the messaging handler definitions 2sf21 and 2sf22. 

Descrfced in a body of the message handler defini- 
tion are the original operations of services provided by 
the server object. The original operations are described 
by the programmer of the server object 40 

At a message handler registration code generation 
step 535, the system generates in registration method 
definition 2sf20, a code for registering in a message 
communication library 21 (refer to Fig. 1) a character 
string corresponding to a conversion of parameters « 
specified in the message description 410 into a stand- 
ard representation based on predetermined rules as 
well as a message handler as arguments. 

Fig. 9 is a structure of an example of the routing 
program compiled and generated by the IDL compiler so 
from the interface definition file 4 shown in Fig. 6. The 
generated routing program 1r is described in source 
level language. Even in this example. C++ is used as an 
example of the programming language after the compi- 
lation. 55 

The routing program 1r is generated by compiling a 
routing program header file 1rf1 and a routing program 
source file 1rf2. 



The routing program header file 1rf1 has an inter- 
face name variable declaration (corresponding to 
"static InterfaceName" given below the Routing Pro- 
gram Class Declaration, a queuing option variable dec- 
laration 1rf11 compiled from the queueing option 
description 4100 (see Fig. 6). and a matching method 
declaration 1ri 12 to be called by a router 12 (see Fig. 1). 

The routing program source file 1rf2 has an inter- 
face name variable declaration (corresponding to 
"static "DigitalLibrary"" given below the Routing Pro- 
gram Class Definition), an external method declaration 
1 rt20 compiled from the native method description 40, a 
queuing option variable definition 1rf21 and a matching 
method definition 1rf22. 

Shown in Fig. 5 is a flowchart for explaining the 
operation of a routing program generation process 5400 
by the routing program generator 54. 

The routing program generation process 5400 is 
called by the parser 51. 

At an interface name variable code generation step 

5401, the system generates a code for initialization of 
an interface name variable (conesponding to the above 
interface name variable definition). 

Next, the system judges at a judgement step 5402 
the presence or absence of an external method declara- 
tion. In the presence of an external method declaration, 
the system generates at an external method declaration 
code generation step 5403 the external method decla- 
ration 1rf20 compiled from the native method descrip- 
tion 40. 

Regardless of the judgement results of the judge- 
ment step 5402, the system judges at a judgement step 
5404 the presence or absence of a queueing option 
description. In the presence of a queueing option 
description, the system generates the queuing option 
variable declaration 1rf11 compiled from the queueing 
option description 4100 and the queuing option variable 
definition 1rf21 at a step 5405 of generating a queueing 
option variable designation value setting code 

Regardless of the judgement result ol the step 

5402, the system generates at a step 5406 of generat- 
ing a matching method declaration code the matching 
method declaration 1rf12 and a prototype declaration 
part (corresponding to "boolean.... message" given 
below the Matching Method Definition) of the matching 
method definition 1rf22. 

Next, at a message pattern comparison code gen- 
erating step 5407, the system generates in the match- 
ing method definition 1rf22, a cods for computing a 
character string corresponding to a conversion of a 
parameter of the message pattern specified in the mes- 
sage description 410 into a standard representation 
based on predetermined rules with a message as an 
argument of Ihe matching method definition 1rf22. The 
system generates a code for returning a 'false' indicative 
of a failure when a coincidence therebetween is not 
found. 

Finally, the system judges the presence or absence 
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of a matching option description at a judgement step 

5408 and. in some cases, generates in the matching 
method definition 1rf22 a code corresponding to a con- 
version of the matching option description 411 at a step 

5409 of generating a matching option description exe- 
cute code. The routing program in the presence of the 
matching description is called a custom routing pro- 
gram. 

Regardless of the judgement result at the judge- 
ment step, the system terminates the operation of the 
routing program generator 54 at an end step 541 0. 
Fig. 10 shows a structure of a message queue. 
A send message queue 1ml, a receive message 
queue 1m2, a transferring send message queue 1m3, a 
temporary keep message queue 1m4. a send message 
queue 2ml, a receive message queue 2m2, a transfer- 
ring send message queue 2m3 and a temporary keep 
message queue 2m4, shown in Fig. 1 have different use 
purposes but all have such a message queue structure 
as shown in Fig. 10. 

The send message queue 1 ml includes a message 
queue ID 1m10 for uniquely identifying a message 
queue and messages 1 ml 1 and 1 ml 2. 

The message 1m11 in turn has a send destination 
message queue ID 1m110 indicative of send destina- 
tion objects, a send origination message queue ID list 
1m111 indicative of send origination objects, an inter- 
face name 1m112 of a service which the send origina- 
tion object is to use, a message body data 1m113 
indicative of a body of the message, and queuing time- 
out time 1m114. 

When consideration is paid to a case of such mes- 
sage integration as will be described later, there exist a 
plurality of such send origination objects, to which end 
the send origination message queue ID list 1m1 1 1 has 
a message queue ID 1 ml 1 1 1 and a message queue ID 
1m1112. 

Fig. 11 shows a structure of a message queue 
information table 30 (see Fig. 1). 

The message queue information table 30 includes 
message queue information items 301 and 302. 

The message queue information item 301 has a 
message queue ID 3010 and a computer address 301 1 
indicative of an address of a computer having the mes- 
sage queue present therein. 

Fig. 12 shows a structure of a routing information 
table 31 (see Fig. 1). 

The routing information table 31 includes interface 
information items 311 and 312 corresponding to serv- 
ices provided by the server object. 

The interlace information item 31 1 has an interface 
name 3110, a routing program designation data 3111 
indicative of a routing program which the router uses for 
determining a message transfer destination, and a 
server object table 31 12 indicative of the server object 
20 supporting the interlace. 

In the present invention, a plurality of the server 
objects 20 can be present to support a single interface. 



to which end the server object table 3112 has message 
queue IDs 31121 and 31122 of the receive message 
queues 2m2 of the server objects 20. 

Shown in Fig. 13 is a flowchart for explaining the 
5 operation of a client stub process 1 caO by the client stub 
1c. 

The client stub process 1 caO is called by the client 
object 10. 

At a message string generation step 1ca1. the sys- 
io tern generates a message string corresponding to a 
method called by the client object 10. 

At a message pattern parameter setting step 1ca2, 
the system sets an argument passed to the method for 
the message string as a parameter. 
is At a step 1 ca3 of setting the interface name of the 
message and the message queue ID, the system sets 
the message queue ID 1m10 of the client object for the 
message queue ID 1m1 11 1 , sets the interface name for 
designation of a send destination of the message for the 
20 interface name 1m1 12, and sets the message string for 
the message body data 1m1 13 to thereby prepare the 
message 1m11. 

Finally, at a step 1ca4 of storing a send message 
queue of the message, the system sets the prepared 
25 message 1mll for the message queue 1ml and then 
terminates its operation at an end step 1ca5. 

Referring to Fig. 14, there is shown a flowchart for 
explaining the operation of a server skeleton process 
2sa0 by the server skeleton 2s. 
so The server skeleton process 2sa0 is called by the 
message communication library 21. 

At a step 2sa1 of registering the routing information 
table of the interface name and message queue ID, the 
system searches the routing information table 31 for the 
35 interface name which the server object 20 supports on 
the basis of such an interface name 3110 as the inter- 
face information item 311 within the table, and when 
finding the interface name, the system registers the 
receive message queue 2m2 of the server object 20 in 
« the server object table 31 12 as the message queue ID 
31121. 

At a step 2sa2 of registering the message pattern 
and message handler, the system registers in a mes- 
sage communication library the messaging handler def- 
45 inition 2sf21 and a message pattern for starting the 
message handler thereof. 

At a step 2sa3 of acquiring a message from the 
receive message queue, the system extracts the mes- 
sage 1m1 1 from the receive message queue 2m2. 
so The system next compares the message body data 
1m1 13 ol the message 1ml 1 with the message pattern 
to judge the presence or absence of the message han- 
dler at a step 2sa4, and in the case of the absence of 
the message handler, the system terminates its opera- 
55 tion at an error end step 2sa5. 

In the presence of the message handler, the system 
calls the message handler with use of the parameter 
extracted from the message as an argument at ames- 
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sage handler starting step 2sa6. 

Thereafter, the system repeats at a step 2sa3 the 
operation of acquiring the message from the receive 
message queue. 

Fig. 15 shows a flowchart for explaining the opera- s 
tion of a message routing process by the routing pro- 
gram 1r. 

First of all, at a slep 1ra0l of acquiring the interface 
name of a head message of a send message queue, 
the routing program 1 r selects one message 1 ml 1 to be 10 
delivered and acquires its interface name 1m112. 

At a step 1 ra02 of judging the presence or absence 
of the acquired interface name 1 ml 12 in Ihe routing 
information table, the system searches the routing infor- 
mation table 31 tor the interface name 1m112 on the is 
basis of such an interface name 3110 as the interface 
information Hem 31 1 within the table. 

If failing to find the interface name, at a step 1ra03 
of storing an error message in the corresponding send 
queue, the system stores the error message in the x 
receive message queue 1m2 and goes to the step 
1ra01 to acquire the interface name of the head mes- 
sage of a send message queue. 

If finding the interface name 3110, at a step 1ra04 
of calling the matching method for the routing program, ss 
the system calls the matching method 1rf22 of the rout- 
ing program 1r specified by the routing program desig- 
nation data 31 1 1 with use of the message body data 
1 ml 1 3 as an argument. 

On the basis of the called result, the system deter- 30 
mines at a slep 1ra05 of judging whether or not the 
matching is successful, the system determines whether 
or not the determination of a delivery destination is suc- 
cessful. 

If failing to determine the delivery destination, the as 
system goes to the step 1ra03 to store the error mes- 
sage in the corresponding receive queue. 

If finding the delivery destination, at a step 1ra06 of 
storing a message in a temporary keep message 
queue, the system stores the message 1m11 in the w 
temporary keep message queue 1m4. 

At this time, the system stores the message queue 
ID 31121 of the server object table 3112 in the send 
destination message queue ID lm110 within the mes- 
sage lm1l, and stores in the queuing timeout time « 
1m1 14 a time corresponding to an addition ol the time- 
out time specified in the queuing option variable defini- 
tion 1rf21 to the storage time. 

Further, at a step 1ra07 of judging Ihe presence or 
absence of Ihe message queue ID. the system performs so 
the operation of the step 1ra06 of storing the message 
in the temporary keep message queue when finding the 
presence of the message queue ID 31122 within the 
server objed table. 

In Hie absence of the message queue ID, the sys- ss 
tern goes to a slep 1ra08 to judge the presence or 
absence of queuing designation. 

The queueing designation, which is a parameter 



designation relating to the message integration, uses 
the value of the queuing option variable definition 1rf21 . 

"The definition value is 0 by default, in which case 
the system regards it as no queuing designation and 
performs no message integration and goes to a step 
1ra11 tojudge the presence or absence of messages. 

In the presence of the queueing designation, the 
system judges whether or not the number of messages 
reaches its maximum. 

The number of message queue IDs within the send 
origination message queue ID list 1m1 1 1 of the tempo- 
rary keep message queue 1m4 corresponds to the 
number of integrated messages. Thus, when the ID 
number is larger than the designated maximum number, 
the system goes to the step 1ra1 1 tojudge the presence 
or absence of messages. 

In the case of absence of messages, the system 
judges whether or not the timeout time expired. 

When the current time goes behind the timeout time 
1ml 14, the syslem goes to the step 1ra1 1 to judge the 
presence or absence of messages. 

In the case of the message absence, the syslem 
goes to the step UaOl to acquire the interlace of the 
head message of a send message queue for process- 
ing of the next message. 

At the step 1ra11 of judging the presence or 
absence of messages, the system searches for the tem- 
porary keep message queue 1m4 and, when the time- 
out time 1m114 of the message 1m11 expires, the 
system goes to a step iral2 to judge whether or not the 
computer addresses are the same. 

If there is no message whose time is behind the 
timeout lime, the system goes to the step 1ra01 to 
acquire the interface of the head message of a send 
message queue for processing of the next message. 

At the step 1 ra1 2 of judging whether or not the com- 
puter addresses are the same, the system compares 
the send destination message queue ID 1m110 of the 
message 1m11 with the message queue ID 3010 stored 
in the message queue information 301 and 302 of the 
message queue information table 30, and acquires the 
computer address 3011 of the coincided message 
queue information 301. 

When the computer address 301 1 is not the current 
computer address, the system goes to a step 1ral3 to 
transfer to the transferring send message queue of 
another computer, and for example, the system trans- 
fers the message 1m11 to the transferring send mes- 
sage queue 2m3 of the computer 2. 

Regardless of the above judgement result, the sys- 
tem proceeds to a step 1ra14 to transfer a message to 
the next corresponding receive message queue. For 
example, the router 22 transfers Ihe message 1m1 1 to 
Ihe receive message queue 2m2 corresponding to the 
send destination message queue ID 1m1 10. 

Thereafter, in order to process another message 
within the temporary keep message queue 1m4, the 
system repeats the operation of the step 1ra1 1 tojudge 
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the presence or absence of a message. 

The embodiment of the present invention has been 
explained above. Another embodiment thereof will be 
explained in detail below. 

Fig. 17 shows a structure of a server object 70 for s 
centralizedly managing several programs for services. 

The service object 70 includes an interlace name 
700, the client stub 1c. server skeleton 2s and routing 
program 1r in the foregoing embodiment 

Shown in Fig. 16 is an arrangement of an inter- jo 
object communication system which uses a dynamic 
service object loader for causing the client object 10, 
server object 20 and router 22 to load the service object 
of Fig. 1 7 as necessary. 

In the present anangement, dynamic object service is 
loaders 6d1, 6d2 and 6d3 and a memory 7m for storing 
the service object 70 therein are additionally provided in 
the entire arrangement of the foregoing embodiment 

The dynamic object service loader 6d1, which is 
called by the client object 10, dynamically loads the 20 
service object 70 and passes the client stub 1c to the 
client object 10. 

Thereafter, the client object 10 utilizes the client 
stub 1c as in the foregoing embodiment. 

Even the dynamic object service loader 6d2 and 25 
6d3 also each perform similar operations in the server 
object 20 and router 22. 

The memory 7m may be placed on the computer 6 
or 3 if necessary. 

The present invention has for example the following 30 
six advantages (1) to (6) in accordance with the afore- 
mentioned method. 

(1) When the client object designates the interface 
name for Hs communication, the service can be as 
used without explicitly designating the server 
object 

(2) The object which provides the service is not 
always single. When the router delivers a message 
to a plural rty of communication destinations, one-to- 40 
multipoint communication can be realized without 
the programmer of the client object recognizes H. 

(3) Even when the object which provides the serv- 
ice is added, deleted or changed, the message can 
be delivered without causing the router to affect the 45 
client object, by the server object causing to suita- 
bly update the routing information (relating to the 
service provided by its own). 

(4) When the service provider or the programmer of 
the server object customizes the routing method for so 
causing the router to determine the communication 2 
destination, finer message delivery control can be 
realized. 

(5) When the service provider or the programmer of 
the server object specifies a method for causing the 55 
router to integrate messages having the same con- 
tents, the amount of messages can be reduced and 
thereby the load of the server object can be 



reduced. 

(6) When the client stub, server skeleton and rout- 
ing program are combined into a single service 
object so that, at the time of execution, the client 
object, server object and router will dynamically 
load the service object respectively; the program 
modules can be centralizedly managed and appli- 
cation installation can be simplified. 

Claims 

1. A method for converting an interface definition 
description in an inter-object communication sys- 
tem wherein a client object (10) operating on erlher 
one of a plurality of computers (1.2,3) in a network 
(8) or on a single computer sends a message to a 
server object (20) operating on the same or another 
computer to execute a predetermined processing 
operation, said method comprising: 

causing an interface definition converting pro- 
gram to convert an interface definition descrip- 
tion described in an interface definition 
language to thereby generate a client stub (1c). 
a server skeleton (2s) and a routing program 
(1r.2r). 

said interface definition description including 
one or more of a method definition description 
of data necessary for said predetermined 
processing operation, and a processing result, 
and a message description specifying a format 
of the message to be sent in response to said 
method definition description, 
said client stub being called to cause said client 
object to send the message, 
said server skeleton including a server registra- 
tion method for storing, in a routing information 
memory routing information for specifying the 
format of said message which said server 
object itself can process when started and also 
including a method for describing said prede- 
termined processing operation to be executed 
when said server object receives the message, 
and 

said routing program judging whether or nol the 
processing of said server object associated 
with said routing information of said message is 
possible through comparison between said 
message and said routing information. 

An inter-objed communication method wherein a 
client objecl (10) operating on either one of a plural- 
ity of computers (1.2,3) in a network (8) or on a sin- 
gle computer sends a message to a server object 
(20) operating on the same or another computer to 
execute a predetermined processing operation, 
said method comprising the steps of: 
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storing a client stub (1c), a server skeleton (2s) 
and a routing program (1r,2r) generated based 
on an interlace definition description; 
when said server object is started, calling a 
server registration method and storing routing s 
information in a routing information memory 
(3m) to cause said client object to call said cli- 
ent stub to send the message and to hold said 
sent message in a send message queue 
(1m1,2m1); 10 
causing a router (12,22) to extract !he message 
from said send message queue, to determine a 
send destination object in accordance with said 
routing program and to add the received mes- 
sage in a receive message queue (1m2.2m2) 75 
associated with said send destination object; 
and 

causing said server skeleton to extract the 
message from said receive message queue 
and causing said server object to execute said so 
predetermined processing operation of the 
message extracted by said server skeleton. 

A method for converting an interface definition 
description as set forth in claim 1, wherein said 25 
routing program adds a queueing option description 
including a message maximum number designation 
and a queueing time designation to a message 
description of said interface definition description, 
compares said message and said routing informa- so 
tion to judge whether or not the processing opera- 
tion by said server object associated with said 
routing information of said message is possible 
and, in the case of presence of said message max- 
imum numbef designation, performs said queueing 35 
option judging operation. 

An inter-object communication method as set forth 
in claim 2, wherein said router keeps the message 
extracted from said send message queue in a tern- 40 
porary keep message queue, and when another 
message has the same contents as said kept mes- 
sage, the router integrates the messages into a sin- 
gle message, and when the number of messages 
within the temporary keep message queue exceeds « 
said message maximum number or when said 
queueing time elapses after said message is 
queued, the router adds said message to a receive 
message queue associated with said send destina- 
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is possible and performs said matching option judg- 
ing operation. 

6. An inter-object communication method as set forth 
in claim 2, further comprising the steps of: 

combining said client stub, said server skeleton 
and said routing program into a single server 
object and storing said service object in a serv- 
ice object memory; 

before said client object sends a message, 
extracting said server object from said service 
object memory 1o call said client stub; 
before said router determines said send desti- 
nation object, extracting said server object from 
said service objecl memory to call said routing 
program; and 

at the time ol starting said server object, 
extracting said server object from said service 
object memory to call said server skeleton. 
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A method for converting an interface definition 
description as set forth in claim 1, wherein, in place 
ol said routing program, a custom routing program 
is generated which compares said message and £5 
said routing information to judge whether or not the 
processing operation by said server object associ- 
ated with said routing information ol said message 
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FIG.6 
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// INTERFACE DEFINITION 
interlace DigitalLibrary { 



// NATIVE METHOD DESCRIPTION 

native boolean isSupportCategory (in string keyword) ; 



40 



41 

cL 



II METHOD DEFINITION 1 

void search (in string keyword) throws InvalidParameterException 



// MESSAGE DESCRIPTION 
message { 
pattern = "search Skeyword"; 



410 

V 



//QUEUING OPTION DESCRIPTION 
maximum = 100 ; 
timeout = 60 ; 



4100 



II MATCHING OPTION DESCRIPTION 
match { 

il (isSupportCategory ($keyword) ) 

return SUCCESS ; 
else 

return FAILURE ; 

}; 
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II METHOD DEFINITION 2 
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FIG.7 

1cf1 

, d 

#indude "MessagingLibrary .h" 

//CLIENT STUB CLASS DECLARATION (DigitalLibrary . h) 
class DigitalLibrary : ClientStub { 

public: 1cf11 



// MESSAGING METHOD DECLARATION 1 




void search (char* keyword) throw (InvalidParameterException) 




// MESSAGING METHOD DECLARATION 2 


}; 1cf12 


#include "DigitalLibraty .h" 


1cf21 


// CLIENT STUB CLASS DEFINITION (DigitalLibrary . cpp) 



//MESSAGING METHOD DEFINITION 1 
void DigitalLibrary : : search (char* keyword) 



throw (InvalidParameterException) { 
if ( (keyword == NULL) 1 1 ('keyword == NULL) 

throw InvalidParameterException ) ; 
char* message = new char [strien(keyword) +8] ; 
'message = W ; 
strcpy (message, "search") ; 

sendMessage ("DigitalLibrary", strcat(message, keyword) ) ; 
delete message ; 

} 

// MESSAGING METHOD DEFINITION 2 

~ ~ ^1cf22 

S 

1cf2 
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FIG.8 



#indude "MessagingLibrary .h" 

// SERVER SKELETON CLASS DECLARATION (DigitalLibiarySkelton. h) 
class DigitalLibrarySkelton : ServerSkelton { 
public : 



2sf1 



II REGISTRATION METHOD DECLARATION 
void register ( ) ; 



// MESSAGE HANDLER DECLARATION 1 
void search (char* keyword) ; 



//MESSAGE HANDLER DECLARATION 2 



2sf10 
2sf11 
2sf12 



#include "Dig italLibrarySkeiton h" 

// SERVER SKELETON CLASS DEFINITION (DigftalLibrarySkeiton. cpp) 



// REGISTRATION METHOD DEFINITION 
void DigitalLibrarySkelton : : register ( ) { 

registerServer ("DigitalLibrary") ; 

registerHandler ("search search) ; 

) 



// MESSAGE HANDLER DEFINITION 1 

void DigitalLibrarySkelton : : search (char* keyword) { 

/ ""describe searching operation. *"/ 

} 



// MESSAGE HANDLER DEFINITION 2 



2sf20 



2sf21 
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II ROUTING PROGRAM CLASS DECLARATION (OigilalLibraryRouter . h) 
class DigitalLibraryRouter : RoutingMethod { 
public : 

static char* InterfaceName; 




// uucuinu UK 1 IUN VAHIABLE DECLARATION 
static long maximum ; 

static long timeout ; 


1rf11 


// MATCHING METHOD DECLARATION 
virtual boolean match (in string message) ; 


1rfi2 


>; 




include "DigitalLibraryRouter h" 

// ROUTING PROGRAM CLASS DEFINITION (DigitalLibraryRouter . cpp) 
static char'DigitalLibraryRouter : : lnterfaceName= n Digital Library" ; 


// EXTERNAL METHOD DECLARATION 

extern boolean isSupportCategory (in string keyword) • 


1rf20 


//QUEUING OPTION VARIABLE DEFINITION 
static long DigitalLibraryRouter : : maximum = 100 ; 
static long DigitalLibraryRouter : : timeout = 60 ; 


1rf21 

1rf22 

( 


//MATCHING METHOD DEFINITION 
boolean DigitalLibraryRouter : : match (in string message) { 
if (IRoutingMethod : : matchfsearch *", message) ) 
return false ; 

if (isSupportCategory(message) ) { 
return true ; 
else 

return talse ; 

} 
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FIG. 12 
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FIG.16 
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fe7) L'invention conceme un precede et dispositrf d'arbi- 
trSge errtre des tiles d'attente dans un reseau de transmis- 
sion numerique. 

Une file cfanente ayant un niveau de priorite attribue. un 
alea est introduit dans la selection des tiles d'attente de 
meme priorite. 

Application: Equipement de brassage el de commutation 
de donnees numeriques notammenl Sans un reseau fonc- 
tionnant en mode de transmission asynchrone (ATM) par 
exemple. 
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La presente invention concerne un procede et disposilif 
d'arbitrage entre des files d'attente dans un reseau de transmission 
numerique. Elle s'applique notammenl aux equipements de brassage et de 
5 commutation de donnees numeriques composant un reseau fonctionnant en 
mode de transmission asynchrone dit ATM, ce dernier terme etant derive de 
I'expression anglo-saxonne "Asynchronous Transfer Mode". Plus 
generalement, I'invention s'applique a tous les reseaux de transmission de 
donnees numeriques ou il est necessaire pour aiguiller ces donnees 
10 d'arbitrer entre files d'attentes en differents points du reseau. 

Les systemes de telecommunication font notamment de plus en 
plus appel au mode de transfert asynchrone ATM. Cette technique de 
transmission permet de vehiculer des informations numeriques de natures et 
de debits aussi varies qu'irreguliers. L'information est transporter a travers 
15 un reseau pouvant presenter diverses topologies, par exemple en maillage, 
en anneau ou en etoile. Chaque noeud du reseau, appele commutateur 
ATM, est relie a un noeud adjacent par une artere de transmission acceptant 
tous types de technologies. La transmission peul done se faire par exemple 
par cable, par faisceau hertzien ou par fibre optique. 
20 Le principe de la technique ATM est de segmenter les donnees 

issues des divers sources en blocs de longueur fixe, et d'ajouter a un bloc 
un en-tete pour former une cellule ATM. Les cellules ATM provenant de 
diverses sources sont alors multiplexees et transmises de facon asynchrone 
sur I'artere de transmission. 
25 Au sein d'equipements ATM, a un instant donne, plusieurs 

cellules peuvent se disputer I'acces a une meme ressource. La mise en file 
d'attente des cellules concurrentes est alors necessaire et il faut par la suite 
choisir selon quel ordre les files d'attente seront servies. 

Dans un equipement, par exemple un commutateur ATM, 
30 possedant Ne ports d'entree et Ns ports de sortie, il est necessaire de mettre 
en file d'attente les cellules recues ou a emettre. Au niveau d'un port 
d'entree. les cellules sont slockees dans differents registres de type FIFO 
selon des criteres precis, par exemple selon la destination, le chemin ou le 
canal virtue!, le port de sortie de I'equipement suivant ou la priorite. Un 
35 registre de type FIFO est un registre connu de I'homme du metier ou les bits 
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sortenl selon leur ordre d'entree dans le regislre, FIFO etant derive de 
I'expression anglo-saxonne "First in, First out". 

Selon I'art anterieur, chaque port possede un algorithme 
d'arbitrage par niveau de priorite qui permet de choisir la file d'attente a 
5 servir parmi toutes celles qui ont la meme priorite. Ce mecanisme se refere a 
une table d'eligibilite qui contient des informations binaires qui selon leurs 
valeurs autorisent ou non de servir un client ou un ensemble de clients. Par 
exemple, cette table d'eligibilite interdit de servir les files d'attente dont les 
cellules sont destinees a des ports de sortie congestionnes. Un des 
10 algorithmes d'arbitrage le plus utilise est connu sous !e terme de "Priorite 
Tournante" ou de "Round Robin". L'algorithme opere independamment d'un 
port d'entree a I'autre. 

Les mecanismes d'arbitrage actuels introduisent plusieurs 
inconvenients, en particulier ils peuvent entrainer une degradation des 
15 performances. Le rendement est ainsi mauvais dans la mesure ou il apparait 
des congestions a I'interieur des commutateurs. II en resulte alors pour 
I'utilisateur final une augmentation des temps de reponse. A terme, I'usager 
est done mal servi. 

Le but de I'invention est de pallier les inconvenients precites pour 
20 permettre notamment un ecoulement efficace el rapide des informations au 
niveau de chaque noeud d'un reseau par exemple asynchrone, et done 
ameliorer le service final pour I'usager. 

A cet effet, I'invention a pour objet un procede d'arbitrage entre 
des files d'attente au niveau d'un noeud d'un reseau de transmission 
25 numerique, caracterise en ce que chaque file d'attente. ayant un niveau de 
priorite attribue, il introduit un alea dans la selection des files d'attente de 
meme priorite. 

L'invention a egalement pour objet un dispositif pour la mise en 
oeuvre du procede. L'invention a pour principaux avantages qu'elle est 
30 simple a mettre en oeuvre et qu'elle est economique. 

D'autres caracteristiques et avantages de l'invention apparaitront 
a I'aide de la description qui suit faite en regard de dessins annexes qui 
representent : 

-la figure 1, un dispositif d'arbitrage fonctionnant selon Tart 

35 anterieur, 
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-les figures 2a, 2b, 2c des illustrations d'un probleme de 
synchronisation mis en evidence par la Deposante, 

- la figure 3, un exemple de mode de realisation possible pour la 
mise en oeuvre du procede selon I'invention. 
5 La figure 1 presente, par un synoptique, un dispositif d'arbitrage 

entre files d'attente au niveau d'un noeud d'un reseau numerique, selon I'art 
anterieur. Un equipement 1 est voue a recevoir des donnees (cellules ATM 
ou paquets ou trames ...) provenant de Ne ports d'entree et a les 
retransmettre sur certains de ses Ns ports de sortie. Les ports de sortie 
10 ayant un debit limite, si tous les ports d'entree presentent des donnees 
destinees au meme port de sortie, il sera impossible de retransmettre toutes 
ces cellules en meme temps. Les cellules qui n'auront pu etre servies seront 
alors mises en files d'attente dans la FIFO du port de sortie destinataire et 
retransmises ulterieuremenl. Lorsque ces FIFO de sortie atteignent un 
15 certain seuil, on dit qu'il apparait une congestion au sein de l'equipement. 
Afin de ne pas aller plus avant dans la congestion, elle doit etre notifiee a 
tous les ports d'entree par I'intermediaire d'un controle de flux entre sorties 
et entrees et/ou pour la mise a jour d'une table d'eligibilite. Ainsi pour 
chaque port d'entree, un arbitre est necessaire pour choisir les files d'attente 
20 a servir parmi celles qui ne sont pas susceptibles d'aggraver la congestion. 
Un algorithme de choix est alors necessaire ; c'est I'algorithme "Round 
Robin", appele encore algorithme a "Priorite Tournante". 

Des cellules arrivent a un noeud, concretise par un equipement 1. 
Cet equipement est par exemple un commutateur ATM. Sa fonction est 
25 notamment d'aiguiller les cellules arrivant sur ses ports d'entree 10,11 vers 
ses ports de sortie 12, 13. L'equipement 1 comporte par exemple Ne ports 
d'entree 10, 11. Une premiere interface d'entree 2 est reliee au premier port 
d'entree 10 de l'equipement 1. Une Ne'eme interface 3 est reliee au Ne '^me 
port d'entree 11. Une interface, par exemple la premiere 2, comporte des 
30 circuits 201, 20P constitues de registres 14 de type FIFO, un premier circuit 
201 conlenant toutes les files d'attente de priorite 1, la priorite la plus 
elevee. un P ieme circuit 20P contenant toutes les files d'attente de priorite 
P, la priorite la moins elevee, et d'autres circuits contenant les files d'attente 
de priorite intermediates. A titre d'exemple, le fonctionnemenl des interfaces 
35 2, 3 est explique relativement aux circuits 201, 301 de priorite 1 de ces 
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interfaces. Un circuit de priorite 1 sera appele par la suite priorite 1. Chaque 
port de sortie du noeud 1 du reseau possede un algorithme d'arbitrage par 
niveau de priorite. 

Une priorite 1 comporte un nombre Ns de registres 14 de type 
5 FIFO, ce nombre Ns etant egal au nombre de ports de sortie de 
I'equipement 1. Chaque registre 14 de la priorite 1 contient une ou plusieurs 
cellules entrantes. Le rang X du registre 14, encore appele numero de FIFO, 
correspond au numero du port de sortie prevu pour la cellule entrante. Le 
numero X de FIFO precite correspond en fait au numero de file d'attente de 
10 la cellule entrante. Par exemple une cellule ayant le rang X est prevue pour 
sortir sur le Xieme port de sortie du noeud 1 du reseau. En cfautres termes, 
une FIFO contient une file d'attente de cellules, la FIFO 14 pouvant 
eventuellement etre vide. 

A chaque priorite 201, 20P, 301, 30P est associe un algorithme 
15 de choix 15 deroule par exemple par un processeur non represents. Les 
algorithmes d'arbitrage generalement utilises sont connus sous ("appellation 
"Round Robin". L'algorithme d'arbitrage 15 associe a la priorite 1 
selectionne un rang X apres avoir selectionne un rang inferieur, et cela 
parmi les FIFO qui ont le droit d'emettre une cellule vers la sortie du noeud 
20 1. Les cellules associees sont dites eligibles, par extension on dira que ce 
sont les rangs ou numeros de FIFO qui sont eligibles. Une table d'eligibilite 
non representee est associee aux priorites ou circuits 201, 20P. Une FIFO 
dont le rang X a ete selectionne emet une cellule vers le port de sortie de 
rang X de I'equipement 1. 
25 Au tour suivant, l'algorithme selectionne un rang suivant, X + 1 si 

celui-ci est eligible, puis le rang X + 2, et ainsi de suite. A chaque FIFO 14 
est associee une adresse de la table d'eligibilite pour aller y lire une 
information binaire sur son etat d'eligibilite. L'algorithme d'arbitrage 15 opere 
done cycliquement sur tous les rangs ou numeros de FIFO 1, 2, ...X, N s 
30 d'une meme priorite, dans Pexemple de fonctionnement explique, il s'agit en 
I'occurrence des registres de priorite 1, done des files d'attente associees. 

La Deposante a mis en evidence des problemes de 
synchronisation de tous les algorithmes d'arbitrage de tous les ports 
d'entree d'un noeud d'un reseau lorsqu'ils sont soumis a de fortes charges 
35 notamment quand toutes les files d'attente, e'est-a-dire toutes les priorites 



5 



2748620 



201, 20P, 301. 308 contiennent des cellules. Le meme phenomene de 
synchronisation peut evidemment se retrouver aussi au niveau des ports de 
sortie s'ils sont connected a un autre noeud du reseau, c'est-a-dire que le 
meme principe peut etre applique entre differents noeuds d'un reseau. Dans 
5 ce cas, les cellules sont rangees en FIFO dont le numero indique le port de 
sotie de I'equipement suivant. Le controle de flux est cette fois transmis 
entre noeuds. 

Deux problemes de synchronisation ont ete mis en evidence par 
la Deposanle. 

10 . Une synchronisation de type convergente apparait lorsque les 

algorithmes de choix evoluent vers un etat de synchronisation ou tous les 
ports, d'entree ou de sortie, servent la meme file d'attente en meme temps. 

Une synchronisation de type aleatoire se produit lorsqu'une 
certaine periodicite dans le choix des files d'attente a servir provoque, a un 

15 instant t imprevisible, la synchronisation des algorithmes independants. A 
cet instant t, les algorithmes presentent differents dephasages les uns par 
rapport aux autres, et ils les conserveront tant qu'ils resteront synchronises. 
Cela signifie notamment que si a I'instant t, une interface d'entree sert la file 
de rang i et une autre interface d'entree sert la file de rang j, alors I'ecart de 

20 dephasage [j-i| restera constant tant que les files d'attente restent toutes non 
vides. 

A ces deux problemes de synchronisation correspondent en fait 
deux types d'algorithmes bases sur des controles de flux differents. 

Dans le cas d'un controle par file, I'algorithme d'arbitrage se 
25 refere a une table d'eligibilite qui indique I'etat de chaque file d'attente. Pour 
chaque cellule d'une file, cette table indique I'autorisation ou I'interdiction 
d'emettre cette cellule vers les ports de sortie du noeud. II apparait alors une 
evolution vers une synchronisation convergente. 

Dans le cas d'un controle global, I'algorithme d'arbitrage se refere 
30 a une table d'eligibilite qui indique I'etat global des files. Cette table indique 
alors I'autorisation ou I'interdiction d'emettre une cellule pour I'ensemble des 
files d'attente. Une evolution tend ici vers une synchronisation aleatoire. 

De ces problemes de synchronisation, il resulte que de 
nombreuses cellules entrenl en conflit lorsqu'elles doivent atleindre la meme 
35 ressource, un port de sortie, au meme moment. Elles congestionnent en fait 



2748620 



6 

la ressource. Ce type de phenomene entraTne ainsi une diminution des 
performances de I'equipement. 

Les figures 2a, 2b et 2c illustrent un probleme de synchronisation 
dans le cas par exemple ou le nombre d'entree Ne du noeud est egai au 
5 nombre de sorties N s . 

La figure 2a illustre un cas sans probleme, un processus 
d'arbitrage dans sa phase initiate par exemple. Dans la premiere interface, 
la file d'attente n° 1 est selectionnee, dans I'interface n° X + 1, la file 
d'attente n° X + 1 est selectionnee, enfin dans !e dernier interface N s ., la file 
10 d'attente n° N s . est selectionnee, puis un nouveau cycle recommence pour 
toutes les priorites 1 des interfaces. 

La figure 2b illustre le debut d'une evolution vers un etat de 
synchronisation. Dans le cas de la figure 2b, le port n° 1 de sortie est par 
exemple soumis a un blocage. Cela arrive notamment si le port de sortie est 
15 congestionne. Si deux cellules veulent au meme instant sortir sur le meme 
port, Tune d'elles pourra effectivement sortir et I'autre sera mise dans la file 
d'attente du port de sortie correspondant. II n'y aura congestion que lorsque 
Tune des FIFO des ports de sortie aura atteint un seuil maximal de 
remplissage. Un controle de flux est ainsi active et sera envoye a tous les 
20 ports d'entree pour que les algorithmes de choix integrent cette information 
dans leur "table d'eligibilite". Le controle de flux ramene a I'entree du noeud 
du reseau interdit alors a la premiere interface de servir la file d'attente n" 1, 
son algorithme d'arbitrage essaie alors de servir la file d'attente n° 2. A 
terme, il apparait une congestion lorsqu'un seuil maximum est atteint par 
25 exemple entre les deux priorites 1 des deux premieres interfaces qui tentent 
en meme temps d'emettre une cellule vers le deuxieme port de sortie du 
noeud 1 du reseau. Le port de sortie n° 2 interdisant son acces, les deux 
premieres interfaces vont alors se synchroniser sur la file d'attente n° 3 
comme i'illustre la figure 2c. A un instant, si plusieurs algorithmes sont 
30 synchronises sur le n° 2 par exemple, la FIFO de sortie du port 2 va grandir 
et risque done rapidement d'atteindre son seuil de congestion. Plus il y a 
d'algorithmes synchronises, plus la probability de congestion augmente. 
d'ou la tendance convergente vers la synchronisation. Un phenomene de 
cascade se poursuit jusqu'au moment ou toutes les interfaces emettent une 
35 cellule sur le meme port de sortie, le dernier port N s par exemple. II n'y a 
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pas de ressource physique comme un bus qui interdise a tous ports d'entree 
d'emettre une cellule vers la meme sortie, lis emettent effectivement tous 
une cellule mais une seule d'entre elles sera emise en sortie, les autres 
seront mises dans la fife d'attente du port de sortie vise. 
5 De ce fait, desirant atteindre un meme port de sortie au meme 

moment, de nombreuses cellules creent done une congestion. Ce type de 
phenomene entraine ainsi une diminution des performances de I'equipement 
telle qu'exposee notamment precedemment. 

Selon I'invention. afin d'eviter toute degradation des 

10 performances, le precede d'arbitrage rompt les cycles qui entrainent une 
synchronisation tout en garantissant requite entre les files d'attente. Pour 
cela le procede introduit un alea dans la selection des files d'attente de 
meme priorite. A chaque choix, selon le procede selon I'invention, une file 
d'attente est par exemple tiree au sort parmi toutes les files d'attente eligible, 

15 sans se preoccuper par exemple des choix precedents. L'equite est garantie 
en moyenne. Ainsi, au lieu de choisir la file d'attente de rang X + 1, si celle- 
ci est eligible, apres la file d'attente de rang X, les moyens d'arbitrage 
permettent de choisir parmi toutes les files d'atlentes eligibles, quel que soit 
leur rang. 

20 Une autre facon pour introduce un alea selon I'invention consiste 

a tirer au sort parmi un nombre donne de files d'attente, par exemple a tirer 
au sort parmi N files d'attente eligibles suivant le rang de la derniere choisie. 
Ainsi si la precedente file d'attente choisie etait X, et si le nombre total de 
files eligibles est N. alors les moyens d'arbitrage autorisent le tirage au sort 

25 d'un nombre R entre 0 et N de telle sorte que la Rieme file d'attente eligible 
a partir de la Xieme file soit selectionnee. La file selectionnee ne sera done 
pas forcement R+X modulo Ns. 

La figure 3 presente un mode de realisation possible d'un 
dispositif pour la mise en oeuvre du procede selon I'invention. Ce dispositif 

30 fournit le numero de la file d'attente a servir. II est associe a un circuit 201, 
20P, 301, 30P de priorite donnee dans une interface d'entree 2, 3. II permet 
done a I'interface de choisir une file d'attente parmi toutes celles d'une 
meme priorite. 

Selon la figure 3 un compteur 41 compte le nombre de files 
35 d'attente qui peuvent etre elues. Pour cela le compteur 41 est relie a la table 
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d'eligibilite 42. Cette table est composee par exempie de N s regislres, N s 
etant le nombre de ports de sortie du noeud du reseau. Le registre n° X 
indique par exempie I'etat d'eligibilite de la file d'attente n° X par une 
information binaire, 1 signifiant par exempie eligible et 0 signifiant par 
5 exempie non eligible. Une file d'attente X est declaree eligible si elle est non 
vide et si le port destinataire n'est pas congestionne. Le compteur 41 compte 
done par exempie le nombre de bits egaux a 1 dans la table d'eligibilite 42. 
Le resultat est compris entre 0 et N s . Un module 43 de generation de 
nombres aleatoires fournit des nombres aleatoires codes par exempie sur 16 
10 bits, a partir par exempie d'un polynome de degre 32. Les possibility de 
choix sont dans ce cas tres importantes. Le nombre aleatoire foumi est 
compris entre 0 et 1, 1 etant exclu. II appartient done a I'intervalle [0, 1[. 

La sortie du compteur 41 indiquant le resultat du comptage de ce 
dernier et la sortie du generateur 43 de nombres aleatoires sont reliees aux 
15 deux entrees d'un multiplieur 44, ce dernier effectuant le produit de ces deux 
entrees, done le produit du nombre de files d'attente eligibles par le nombre 
aleatoire foumi. Le nombre Ns de ports de sortie est par exempie tel qu'il 
peut etre code sur 5 bits. Le multiplieur 44 effectue un arrondi afin de 
presenter a sa sortie un nombre entier compris entre 1 et Ns. Le multiplieur 
20 44 permet de realiser un tirage aleatoire equitable d'un nombre entier 
compris entre 1 et N, avec N variable entre chaque tirage. Une autre 
solution aurait pu etre de tirer au sort un nombre tres grand compris entre 1 
et 2P-1 (tirage au hasard classique puisque les deux bornes sont fixes), puis 
exprimer le resultat en entier sur 5 bits modulo N (N = nombre de files 
25 eligibles) +1. On obtient ainsi un nombre compris entre 1 et N, mais la 
realisation d'un modulo N (avec N non puissance de 2) n'est pas tres aise. 
De plus pour etre certain d'avoir un tirage aleatoire equitable, il faut que p 
soit tres grand. On voit done les avantages en terme de simplicity et d'equite 
apportes par la solution proposee dans le dispositif de la figure 3. 
30 La sortie du multiplieur 44 est reliee a une entree d'un premier 

multiplexeur 45. I'autre entree de ce multiplexer ayant un etat logique 
constant egal a 1. Ce multiplexeur 45 est commande par un signal binaire 
M1. Sa sortie est reliee a une premiere entree N d'un circuit de selection 46. 

La sortie d'un deuxieme multiplexeur 47 est reliee a une deuxieme 
35 entree R du circuit de selection 46. Une premiere entree du deuxieme 
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mulliplexeur 47 est a I'elat logique 0 alors que I'autre entree est reliee a la 
sortie d'une memoire 48 qui memorise la sortie du circuit de selection 46. 
Cette memoire 48 memorise en fait la derniere file d'attente servie. 

Le circuit de selection parcourt la table d'eligibilite a partir du rang 
R + 1, R etant le nombre affiche a sa deuxieme entree R. II parcourt a partir 
de ce rang R + 1, N registres eligibles successifs, a I'etat 1 par exemple, de 
la table d'eligibilite. II presente a sa sortie le rang du dernier registre 
parcouru, par exemple R + 1 + N si tous les registres sonl eligibles. Si le 
compteur 41 compte un resultat nul, il desactive le circuit de selection 46 
dont la sortie reste alors figee. Le compteur 41 est re|ie a une entree 
d'activation du circuit de selection 46. Le compteur indique si son resultat 
est nul par une information binaire. Cette derniere est aussi combinee avec 
la sortie du circuit de selection 46 par I'intermediaire d'une porte "et" 49. La 
sortie de cette porte est a zero si le compteur est a zero, dans ce cas 
aucune file d'attente n'est a servir. Le circuit de selection 46 ayant ete 
desactive, le numero de la derniere file d'attente servi est conserve en sortie 
du circuit. II est done possible de reboucler sur ce dernier quand des files 
d'attente seront de nouveau a servir. Si le compteur affiche un resultat non 
nul, la porte "et"49 reproduit la sortie du circuit de selection. La porte "et" 49 
fournit en sortie le numero de file d'attente a servir. Ce numero est par 
exemple lu par un processeur qui active par exemple le registre ou la FIFO 
correspondante. 

Les differents circuits, notamment le compteur 41 et le module 43 
de generation de nombres aleatoires, sont par exemple synchronises par un 
signal d'horloge non represents, ou bien par un signal commande par un 
processeur, chaque signal de synchronisation correspondant a une nouvelle 
selection de file d'attente. 

Les informations binaires M1, M2 qui commandenl les deux 
multiplexeurs permettent de configurer le fonctionnement de I'ensemble. 

Si M1M2 = 11, la premiere entree N du circuit de selection est 
forcee a 1 et la deuxieme entree R reproduit le dernier numero de file 
d'attente servie. Apres la file d'attente de rang R, celle de rang R+1 est ainsi 
selectionnee. puis celle de rang R+2 et ainsi de suite. Un algorithme 
cyclique de type Round Robin est alors en fonctionnement. Aucun alea n'est 
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introduil, c'est le cas decrit precedemment qui peut amener, dans certaines 
circonslances a une diminution globale des performances de I'equipement. 

Si M1M2 = 00, la deuxieme entree R est forcee a zero et la 
premiere entree N du circuit de selection 46 comporte le resultat du 
5 compteur 41. Apres chaque selection, une nouvelle file d'attente est alors 
choisie au hasard parmi toutes celles eligibles. 

Si M1M2 = 01, la deuxieme entree R reproduit le numero de la 
demiere file d'attente selectionnee et la premiere entree N du circuit de 
selection 46 comporte le resultat du compteur 41 . 
o Si M1M2 = 10, la premiere entree N est fixee a 1 et la deuxieme 

entree R du circuit de selection 46 est fixee a 0. La premiere file d'attente 
eligible a partir de la premiere file d'attente est alors selectionnee. 

Les circuits de la figure 3 pourraient par exemple etre remplaces 
par un microcontroleur integrant les fonctions de lous ces circuits. 
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REVENDICATIONS 

1. Procede d'arbitrage entre des files d'attente (14) au niveau d'un 
noeud (1) d'un reseau de transmission numerique, caracterise en ce que 

5 chaque file d'attente ayant un niveau de priorite attribue, il introduit un alea 
(43) dans la selection des files d'attente de meme priorite. 

2. Procede selon la revendication 1 , caracterise en ce qu'une file 
d'attente (14) est tiree au sort parmi toutes les files d'attente autorisees a 

10 emetlre une cellule. 

3. Procede selon la revendication 1 , caracterise en ce qu'une file 
d'attente (14) est tiree au sort parmi un nombre donne de files d'attente 
suivant le rang de la derniere file d'attente selectionnee, et parmi les files 

15 d'attente autorisees a emettre. 

4. Dispositif d'arbitrage entre des files d'attente (14) au niveau 
d'un noeud (1) d'un reseau de transmission numerique, caracterise en ce 
qu'une file d'attente ayant un niveau de priorite attribue, il comporte des 

20 moyens de selection (46) des files d'attente de meme priorite et des moyens 
(41, 42, 43. 44, 45, 47, 48) pour introduire un alea dans les moyens de 
selection (46). 

5. Dispositif selon la revendication 4, caracterise en ce que les 
25 moyens pour introduire un alea component un module (43) pour generer un 

nombre aleatoire, les moyens de selection (46) operant une selection des 
files d'attente fonction de ce nombre aleatoire. 

6. Dispositif selon I'une quelconque des revendications 4 ou 5, 
30 caracterise en ce qu'il comprend des moyens (45, 47, M1, M2) pour 

configurer la selection des files d'attente, avec ou sans alea. 

7. Dispositif selon I'une quelconque des revendications 4 a 6, 
caracterise en ce qu'etant relie a une table d'eligibilite (42) des files 

35 d'attente, les moyens de selection (46) selectionnent une file d'attente parmi 
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toutes les files d'attente eligibles, une file d'attente eligible etant une file 
d'attenle autorisee a emettre une cellule. 

8. Dispositif selon Tune quelconque des revendicalions 4 a 6, 
5 caracterise en ce qu'etant relie a une lable d'eligibilite (42) des files 

d'attente, les moyens de selection (46) selectionnent une file d'attente parmi 
un nombre donne de files d'attente eligibles a partir de la derniere file 
d'attente selectionnee. une file d'attenle eligible etant une file d'attente 
autorisee a emettre une cellule. 

10 

9. Dispositif selon Tune quelconque des revendications 
precedentes, caracterise en ce qu'il comporte au moins : 

- un generateur (43) de nombre aleatoire compris entre 0 et 1 

- un compteur (41) comptant les files d'attente eligibles dans une 
15 table d'eligibilite (42) 

- un multiplieur (44) effectuant le produit du nombre aleatoire par 
le resultat du compteur (44) 

- un circuit de selection (46) parcourant un nombre N de registres 
eligibles successifs de la table d'eligibilite (42), le nombre N etant le produit 

20 du multiplieur (44), le circuit de selection presentant en sortie le rang du 
dernier registre parcouru, chaque registre de la table d'eligibilite etant 
associe a une file d'attente, un registre eligible indiquant que sa file d'attente 
associee est autorisee a emettre une cellule, la sortie du circuit de selection 
(46) indiquant le numero de la file d'attente selectionnee. 

25 

10. Dispositif selon la revendication 9, caracterise en ce qu'il 
comporte un multiplexeur (45) intercale entre le multiplieur (44) et le circuit 
de selection (46), le multiplexeur etant commande par un bit de configuration 
(M1) pouvant forcer la sortie du multiplexeur a 1. 

30 

11. Dispositif selon Tune quelconque des revendications 9 ou 10, 
caracterise en ce qu'il comporte une memoire (48) reliee en sortie du circuit 
de selection (46), la sortie de la memoire etant reliee a I'entree d'un 
multiplexeur (47) dont la sortie est reliee a une deuxieme entree (R) du 

35 circuit de selection (46), le multiplexeur (47) etant commande par un bit de 
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configuration (M2) pouvant forcer sa sortie a 0, le circuit de selection (46) 
parcourant la table d'eiigibilite (42) a partir du rang correspondant au 
nDmbre affiche sur sa deuxieme entree (R). 
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NOVELTY - A device for controlling a queue for a communication 
between tasks and a method thereof are provided 'to enhance the 
performance of a system and manage a queue effectively by managing 
registrations of many queues being recognized in a main CPU board 
and an error message being asked in a general operating system in 
one place and transmitting a message to the final destination of 
each queue rapidly. 

DETAILED DESCRIPTION - A task(100) performs a command inputted in 
an operator managing program. A processor ( 110 > controls a program. 
A queue manager (120) supplies a message queue registration, a 
query function, and a transmission function. A queue thread(130) 
transmits/receives messages being transmitted and received to a 
remote place board to an IPC drive. A queue table (14 0) is used 
for storing and routing information of a queue being used in a 
system. A software block manufactures one's queue and requests a 
message queue registration to the queue table (140) through 
the queue manager (12 0) . When the message is transmitted to other 
block, a query is processed for selecting a message queue for a 
transmission, and the queue table(140) is checked, and an ID 
of a destination queue is searched. A registered queue is 
designated as a block ID and an interface ID and used by attaching 
to a header in a message transmission. The queue thread (130) 
transmits a message transmission request to an IPC drive. The IPC 
drive transmits a message transmission request signal being 
transmitted from the queue thread(130) to the destination queue. 
In case that a responded block is in other unit, a message 
routing is performed. At this time, a mapping of the queue 
table (140) is performed by referring to a header of an IPC 
message. The destination queue reports a message result to the 
queue thread(130) again . (Dwg . 1/10 ) 
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